home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2258 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: ludens.elte.hu!genie
  2. From: genie@ludens.elte.hu
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Removing a patch -A POSSIBLE SOULTION
  5. Message-ID: <1996Jan29.141204.23597@ludens>
  6. Date: 29 Jan 96 14:12:04 +0200
  7. Organization: Eotvos University, Budapest, Hungary
  8.  
  9.  
  10.   Hi to All,
  11.  
  12.  I got a fine reaction on my latest posting about the removing a patch problem,
  13. so I decided to make my possibly working version available to the public. Just
  14. in a nutshell, I will give an EXTREMELY SIMPLIFIED assembly code section with
  15. some comments in the end. (I guess you don't like reading a lot.)
  16. Let's see then...
  17.  
  18. The code for the patch which is SetFunctioned somewhere looks like this:
  19.  
  20. PatchMan:    addq    #1,UseCount    ;how many tasks using this patch?
  21.         tst    PatchEnabled    ;is it still installed?
  22.         beq    .doorig
  23.         jsr    MyPatch        ;replacement for the old function
  24.         subq    #1,UseCount    ;done with it
  25.         rts
  26. .doorig:    move.l    OrigFunc,-(a7)
  27.         rts
  28.    
  29.  And supposing the patch is already installed, we should remove it somehow:
  30.  
  31. RemPatch:    libcall    Forbid        ;avoid rescheduling
  32.         tst    UseCount        ;still some users?
  33.         beq    .removeit
  34.         libcall    Permit          ;enable rescheduling
  35.         bsr    WaitSomeTime    ;let them work on
  36.         bra    RemPatch        ;then try again
  37. .removeit:    clr    Enabled         ;we can disable it now
  38.         libcall    Permit          ;let them run
  39.         move.l    #MyPatch,a1
  40.         libcall    FreeMem        ;now we can safely get rid of it
  41.         rts
  42.  
  43. That's what it is. Consider it carefully with many possible and impossible
  44. scheduling steps. I have tried this scheme, and it proved to work fine and
  45. 100% safely. Maybe it's not a brand new idea, but I haven't seen this before.
  46. Was I blind?
  47.  
  48. Some comments:
  49. 1, The PatchMan routine must stay resident forever, but it really doesn't
  50. eat up too much space, nor consumes much time.
  51. 2, All the signals (UseCount, Enabled) should be stored in public semaphores.
  52. 3, Removing the patch can last for a while if many tasks are using the
  53. function. It may even freeze in a really WEIRD situation, but its
  54. possibility is VERY near to 0. This time could be significantly(?) reduced
  55. if the WaitSomeTime function sleeps for random selected times in a given
  56. interval. 
  57. 4, With the use of named semaphores, many patches could be handled by
  58. only one resident module. It might be a good idea to implement functions
  59. like SetNamedPatch, IsNamedPatchInstalled, QueryNamedPatches and so in
  60. a shared library, so they could be easily used. Or do you think it isn't
  61. worth the effort and would be useless anyway? I've heard of a 
  62. patch.library some time ago, but have never seen it. Maybe it's a similar
  63. solution for the problem.
  64.  
  65. Good for a discussion, isn't it? Any thougths?
  66.  
  67. Sorry for bothering, and sorry for my weak English as well,
  68.  
  69.             Genie  
  70.  
  71. --------------------------------------------------------------------------------
  72.      ///  Kertai 'Genie' Gabor                     | PGP fingerprint:
  73.     ///   from Eotvos Lorad University of Sciences |   32 36 96 9A 15 61 03 98
  74. \\\///    Budapest 1038, Eszak u. 39., Hungary     |   7D D3 29 14 84 27 78 AC
  75.  \XX/     E-mail: genie@ludens.elte.hu             | Public key via finger...
  76. --------------------------------------------------------------------------------
  77.